Thanks for your attention. We will review it and get back to you soon.

Reference Implementation Available

We have built and deployed a working ContextEngine plugin that implements the design described in this PR. It has been running in production on Hermes Agent v0.16.0 for several days, replacing hermes-lcm as the sole context engine.

What we built

A standalone Python plugin (tencentdb-offload) that:

• Implements all 4 abstract ContextEngine methods (name, update_from_response, should_compress, compress)
• Talks exclusively to the offload V2 API (POST /v2/offload/compact, POST /v2/offload/ingest)
• Has zero dependencies on TencentDB internals — HTTP-only contract
• Includes graceful fallback (tail-truncation with tool-pair preservation) when the Gateway is unreachable
• Thread-safe compress() with lock-free HTTP calls
• Background after_tool_call hook for L1 ingest
• 8 unit tests, stdlib-only

Architecture validation

The implementation closely follows the "Proposed Architecture" section in docs/hermes-context-engine-plan.md:

Key design decisions worth noting

1. HTTP-only API contract: The plugin does not import any TencentDB Python/TS code. This means any server upgrade that preserves the V2 API is automatically compatible. We recommend this as a hard constraint for the official implementation.

2. Fallback is essential: The Gateway can be down, slow, or return errors. A local tail-truncation fallback ensures sessions never deadlock. This should be part of the official spec, not an afterthought.

3. register_context_engine availability check: Older Hermes versions may not have this method. Graceful degradation is important for adoption.

Configuration

# config.yaml
context:
  engine: tencentdb-offload
plugins:
  enabled:
    - tencentdb-offload

# .env
TENCENTDB_OFFLOAD_THRESHOLD=0.4
TENCENTDB_OFFLOAD_GATEWAY_URL=http://127.0.0.1:8420

Compatibility

• TencentDB Agent Memory v1.0.0+ (offload V2 API)
• Hermes Agent v0.16.0+
• Python 3.10+, no external dependencies

We are happy to contribute this as a starting point for the official hermes-plugin/context-engine/ directory, or keep it as a community plugin. Either way, this validates that the design plan is sound and implementable with minimal complexity (~440 lines of Python).

If there is interest, we can open a PR to add this under hermes-plugin/ alongside the existing memory_tencentdb provider.

Hi @Maxwell-Code07 — gentle ping on #214.

You originally said "Thanks for the PR! We'll review the tool registration fix" (that was actually for #220; #214 you said "Thanks for your attention. We will review it and get back to you soon"). Since then, @ysun0804 publicly shared a working production ContextEngine plugin that implements the design in this plan, which is a strong external validation.

I rebased onto current main (4339e63) — CI green (Install / Manifest / Pack / Size Guard all success on 1387c7f). Two questions:

1. Is the plan-only PR ready to land as-is, or do you want a runtime follow-up PR first?
2. Given feat(hermes): add offload context engine #376 already covers the runtime adapter side on main, would merging the plan in docs(hermes): plan context engine support #214 make sense as design documentation alongside the implementation?